Conversation Patterns: Workshop Report

In a service-oriented architecture systems communicate by exchanging messages. Message passing provides for robust and loosely coupled interaction but it also provides less structure than traditional RPC models, which are based on a fairly rigid request-response interaction style. Instead, messages exchanged over time between a set of parties can form a multitude of conversations. An expressive contract between communicating parties should define a coordination protocol that describes which conversations are legal. Such a protocol can be expressed in different ways, for example through choreography or public endpoint process definitions. The purpose of conversations patterns is to document common forms of conversations in the design pattern format, highlighting design trade-offs and popular implementations. As part of the Dagstuhl Seminar 06291 on The Role of Business Processes in Service Oriented Architectures in July 2006 we held a Workshop on Conversation Patterns. In this paper, we report on the results of this workshop. Introduction Design patterns have established themselves as a valuable design and learning tool in the software development community. Originating from the design and architecture of cities and buildings [APL], design patterns capture knowledge as "mind-sized" chunks in a structured format. The format describes the context in which the problem occurs, discusses the forces affecting any potential solution, and provides a good, known solution, followed by implementation guidance. Each design pattern is identified by a name that forms part of a larger pattern language. Many existing design patterns are based on an object-oriented programming model (for example, [GOF], [POSA]) but the technique has been successfully extended to other programming models, such as asynchronous messaging [EIP]. Capturing knowledge as design patterns has proven particularly useful in areas where programming models are less familiar and design choices are manifold. Services, the elements of a service-oriented architecture, interact through the exchange of messages. A conversation is a set of related messaged exchanged by multiple interacting parties, that each play a defined role in the conversation (see also [WEB]). A very simple conversation may consist of one message sent from a service consumer, followed by a response message sent by the service provider. This conversation defines two roles, consumer and provider, and two messages. The rules of the conversation state that the conversation begins with a single request message, which is always followed by a single response message. Describing the rules of a conversation has been the subject of a multitude of specifications, such as WSCL (Web Services Conversation Language), WSCI (Web Service Choreography Interface), WS-CDL (Web Services Choreography Description Language), BPML (Business Process Modeling Language), and WS-BPEL (Business Process Execution Language). Each specification defines a structured language that expresses the relationship between individual messages that Dagstuhl Seminar Proceedings 06291 The Role of Business Processes in Service Oriented Architectures http://drops.dagstuhl.de/opus/volltexte/2006/828 Dagstuhl Seminar 06291 Conversation Patterns: Workshop Report 2 make up the conversation, for example whether messages are required or optional, or specific ordering constraints between messages. The most relevant (and to some extend competing) specifications today are WS-CDL and WS-BPEL. WS-CDL describes the overall choreography that covers the message exchange between multiple participants from the viewpoint of a neutral observer. WS-BPEL on the other hand defines an abstract process template that governs the rules of the message exchange by embedding send and receive elements inside a process definition. The BPMN (Business Process Modeling Notation) expresses conversations similarly by defining partner processes along with the messages exchanged between them. The multitude of standardization efforts highlights the fact that describing conversations in a precise and intuitive manner is not trivial. Conversation share many challenges with traditional protocol design, such as avoiding deadlock or livelock situations. Many application programmers are less familiar with these kinds of issues, making conversation design a tedious and often errorprone activity. Competing specifications also make it difficult for developers to settle on an implementation language. The fact that none of the aforementioned specifications include a visual notation, often forces developers to communicate their conversation designs in slightly cryptic XML files or very informal sketches. To allow a broader set of developer to successfully define conversations without having to dive into the details of one of the specification languages is the goal of a catalog of conversation patterns. A sample of the conversation patterns identified and cataloged at this time is given in [DAG]. Workshop Goals The workshop was organized around the following goals: • Notation: can we find a visually intuitive notation that is expressive and precise? • Categorize patterns: how can we group individual patterns into categories? • Composability: can individual conversation patterns be combined into larger patterns? Do we need a formal description of such composition? • Discover patterns: brainstorm on new pattern candidates that participants have observed in practice. • Related work: identify related works and highlight commonalities and differences. Identify opportunities for collaboration. • Formalisms: Assess the value of a precise (formal?) representation of the patterns in addition to the purely textual description. As this is a fairly ambitious list of goals for a two-hour workshop we were not able to address all topics in equal depth. Notation Depicting conversations in a visually expressive, precise and intuitive form is not easy. As mentioned, the standardization efforts (with the exception of BPMN) do not include any notation. During our workshop we discussed the following options: UML 1.x sequence diagrams – these diagrams are familiar to most developers and reasonably visually expressive. However, these diagrams cannot express the coordination protocol, i.e., the rules of the conversation; they simply represent a single example conversation. Therefore, multiple sequence diagrams would be needed to enumerate valid conversations.